The three QA screens each derived their step statuses inline, as private
computed properties on the View. Nothing could check them without building a
screen, and none of the defects they carry is visible to a test that renders.

This moves them to Example/PayabliDemo/Flow/ as pure functions and changes
nothing about what they decide. The bodies are a transliteration: the recorded
activation outcome is still read before the sequence has reached activation,
the charge step still consults the session rather than the step in front of it,
and the PayIn result step still keys off a result arriving rather than the form
finishing.

The vocabulary is Android's, so the two platforms name these the same things:
StepStatus, FlowStep, StepRow. The QA prefix named an audience rather than a
thing, and the demo runs against sandbox and production as readily as QA.

The tests land here, red: 18 of 40 fail, 214 assertions, over 144 Tap to Pay
combinations and 64 per card-not-present entry point. The next commit makes
them pass. Check this one out to watch them fail.

They live in a new PayabliDemoFlowTests target with no host application.
Secrets.swift is gitignored and is a member of the app target's Sources phase,
so the app cannot compile on a clean checkout and cannot host anything.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CI ran one xcodebuild and nothing else. It now runs, in order: swiftlint and
swiftformat --lint, the SDK suite, the demo's step sequences, and SonarCloud.

swiftlint is invoked with no --config. Naming a config file makes SwiftLint
ignore nested ones, and Tests/.swiftlint.yml is what relaxes the rules XCTest
fixtures break: with --config the count goes from 29 warnings to 104 with one
serious, and the step fails. The config's own header claimed CI already ran
`swiftlint --strict`; it ran no lint at all, and --strict exits 2 on the
warnings in the tree today. The header now says what CI does.

The demo's tests need their own scheme and their own invocation: the bundle has
no host application, because Secrets.swift is gitignored and belongs to the app
target. Proved by running it with Secrets.swift moved aside.

Sonar follows sdk-android: SonarCloud, organization payabli, key
payabli_sdk-ios. Both prerequisites are already in place, checked rather than
assumed — the project is live under that key and SONAR_TOKEN has been a
repository secret since 28 July.

Swift coverage has no native importer, so
Scripts/xccov-to-sonarqube-generic.sh converts both .xcresult bundles into the
generic format — 120 files, 16,142 lines, 12,393 covered. It exits non-zero
when it finds no covered files, because an empty report reaches Sonar as 0%
coverage and reads like a measurement. Paths are repo-relative so the report
survives the hand-off between jobs.

Coverage exclusions mirror Android's reasoning: a SwiftUI view needs a
rendering pass, so the sample app's view directories are excluded and Flow/ is
not.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…records for it

`activateDevice` calls markError when it is refused, so the session reads
`.error` for a failure that belongs to activation. The enable step took that
`.error` as its own, and the guard added in the previous commit then blocked
activation — hiding the reason and the retry, which is what the code this
replaced was avoiding by reading the outcome first.

The enable step now hands the `.error` on when an activation failure is
recorded. Expiry is not activation's doing, so `.sessionExpired` still belongs
to enable whatever a stale outcome says, and a test holds that line.

Three tests, two of which fail before this: the point case, an invariant over
every `.error` combination that a recorded activation failure is answered by
the activation step, and the expiry case that stops the fix over-reaching.

The 144-combination sweep did not catch this. Its invariants asked whether two
steps could speak at once, never whether a recorded failure still had a voice.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`activateDevice` throws `.invalidState` unless the session is
`.pendingActivation`, and a refused activation leaves it `.error`. The
activation step rendered its code control there anyway, beside the
Re-initialize the same session state puts on screen: two next actions, one of
which throws on the first tap.

The sequence now carries `acceptsActivationCode` and `offersRecovery`, and the
screen reads both. The failure still reports its reason; what goes away is the
control that cannot run. Recovery was deciding this for itself in the view,
which is why no test could see it.

Two invariants over the 144 combinations: the code control appears only for
`.pendingActivation`, and never alongside Re-initialize.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…iew read it

Recovery was a flag of its own, keyed on the session alone. With a failed probe
and a broken session the token step offered its retry while Recovery offered
Re-initialize: two next actions, and Re-initialize re-runs config, which a
backend known to be down cannot answer.

That is the third variant of one defect in three rounds, each time from adding
a boolean beside the steps instead of ordering the actions the way the steps are
ordered. `acceptsActivationCode` and `offersRecovery` are replaced by
`nextAction`, derived in the same pass and in the same order, and every control
on the screen renders only when it is that action.

A step still reports where it has got to; the two are separate because a step
reports failures it cannot retry. A refused activation shows its reason while
Re-initialize is the way forward.

Four invariants over the 144 combinations: the activation code only for
`.pendingActivation`, a charge only for `.ready`, Re-initialize only once the
token step has finished, and a failed probe holding the action on the probe
whatever the session says.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…activation

Activating writes `.enableFailed` when the code is accepted and the
`initialize()` after it is not, and it puts the reason in the enable step's
message: "Activated. Enabling the terminal failed — see step 2." When `/config`
answers 403 again the session goes back to `.pendingActivation`, which this step
read as finished. Step 2 was `.done` and hid the message it had just been told
to show, and step 3 asked for another code for a device already activated.

`.pendingActivation` now finishes the enable step only when no enable failure is
recorded, and the enable retry is offered from `.failed` as well as `.current`.

Two tests: the point case, and every combination carrying `.enableFailed` past
a finished token step.

`.enableFailed` was listed as written-and-never-read when this branch started,
and left that way on purpose. Reading it is what this needed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`testCardReadFailureKeepsTheSessionReady` failed on CI and passed on a re-run of
the same commit. The cause is not the runner: `bounded` slept a hardcoded five
seconds while `boundSeconds` sat beside it, declared, documented and never
referenced.

Its own comment says what the number is for:

    for the slowest machine that runs this, not the fastest: an existing test
    in this suite takes eighteen seconds on CI and milliseconds locally.

Five seconds is under a third of the eighteen that comment records. Measured
here, the test runs in two to nine milliseconds, so the bound was three orders
of magnitude tighter than the work and still short of what CI does.

What the bound catches is a call that never returns, and sixty seconds catches
that as surely as five while leaving room for a machine that stalls.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`Latch.enter` incremented the count and `Latch.hold` stored the continuation, as
two calls on the actor. The test waited on the count, so it could reach
`release(2)` after the second run was numbered and before it was registered.
That release found nothing to resume and was dropped, and the run then waited
for a release that had already happened: `await second.value` never returns and
the case hangs until XCTest gives up, which reports nothing about the defect.

`hold()` now numbers and registers in one call, with no suspension between the
two lines, so a run the test can count is a run the test can release.

Ten consecutive runs of the class pass. The previous structure was not observed
hanging, because the interleaving it allows is the rarer one; it is removed
rather than measured, since the failure it produces is a hang.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`ci.yml` is triggered by `pull_request`, and GitHub runs the head revision's
copy of it. A same-repository pull request is granted the repository's secrets,
so a branch could add a step to the analysis job and read `SONAR_TOKEN`, or to
the comment job and read the write token. Splitting the token into a job that
checks nothing out did not close that: the job's steps are still written in the
branch's copy of the file.

Both move to `pr-reports.yml`, triggered by this workflow finishing. GitHub
triggers `workflow_run` only for a workflow file that exists on the default
branch, and runs that copy, so those two jobs are no longer editable by the
pull request they report on. Nothing left in `ci.yml` holds a secret or a write.

A `workflow_run` job has no pull request of its own, so the number, head ref and
base ref travel in the artifacts as `pr.json`. They are passed through `env` and
written with `jq`: a branch name is chosen by whoever opens the pull request and
`${{ }}` pastes it into the shell before the shell sees it, so a branch called
`$(...)` would otherwise run as a command in a job that now holds a token. The
readers parse the file rather than sourcing it, and refuse a ref carrying
anything but the characters git needs. On a push there is no `pr.json`, and its
absence is what selects a branch analysis over pull request decoration.

Checked locally against the three inputs: a real pull request yields the three
`sonar.pullrequest` arguments, a branch named `evil$(id)` is refused and reddens
the job, and an absent file analyses a branch. `actionlint` passes on both
files.

What this cannot buy: the scanner needs the head revision in the workspace, so
that job still checks the pull request's source out while holding the token. It
runs nothing from the tree, and the coverage it reads was produced by the run
that triggered it, but the protection is over the workflow definition rather
than over what is analysed.

The cost, stated because it is not recoverable from the diff: a `workflow_run`
workflow does not run until it is on the default branch, so this pull request
has no change-report comment and no analysis check until it merges, and neither
job can be exercised before then.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit moved the tokens into a workflow the branch cannot edit and
then handed that workflow a number the branch chose. `ci.yml` runs from the head
revision, so `pr.json` was attacker-controlled input: a branch could write
another open pull request's number into it and have the trusted workflow delete
that pull request's change report and post whatever this branch's script had
produced in its place, and file this revision's analysis against it.

Both jobs now read `github.event.workflow_run.pull_requests[0]`, which GitHub
fills in from the triggering run and a branch cannot write to. `pr.json` is gone
from both artifacts rather than validated, since checking the shape of a number
says nothing about whose number it is.

Both jobs also require the triggering run's head repository to be this one. A
fork has no entry in `pull_requests`, so there would be nothing trustworthy to
name, and the analysis job would otherwise check a fork's revision out while
holding the token.

The refs still reach the scanner as command arguments, so they are matched
against the characters git needs rather than trusted.

Checked locally against the four inputs the step can receive: a pull request
yields the three `sonar.pullrequest` arguments, an absent number analyses a
branch, and a branch named `evil$(id)` or a number reading `24; rm -rf /` is
refused and reddens the job. `actionlint` passes on both files.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`ci.yml` set no top-level `permissions`, so every job took the repository's
default grant. That default is read-only today, and it is a repository setting
rather than a property of this file: raising it would hand a write to jobs that
run the pull request's own local action and scripts, which is the opposite of
what the comment at the top of the file claims.

The workflow now pins `contents: read`, and each checkout sets
`persist-credentials: false`, since nothing here pushes and the token was
otherwise left in `.git/config` for whatever ran next.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`pr-reports.yml` had no concurrency of its own. `ci.yml` cancels a superseded
run, but cancelling is not instant: a run already at its last step finishes, and
the push that superseded it produces a second, so two report jobs can be in
flight for one pull request. Both list the comments, both delete what they
found, and the loser of that race deletes a comment that is already gone and
reddens on it; on the other ordering both post and the pull request carries two.

Each job is now keyed by the pull request the event names, and a newer run takes
an older one's place, since the older one is reporting on a revision that has
been replaced.

The analysis has the same race for the same reason, and was not in the review:
two analyses of one pull request reach the server in whichever order they
finish, so the later revision's numbers can be overwritten by the earlier one's.
A push run names no pull request and is keyed by its branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>